home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / The World of Computer Software.iso / jdic15.zip / JDIC15.DOC < prev    next >
Text File  |  1991-12-11  |  17KB  |  382 lines
  1.  
  2. J D I C 
  3.  
  4. English Japanese Dictionary Display 
  5. =================================== 
  6.  
  7. Version 1.5 (November 1991)
  8.  
  9. INTRODUCTION 
  10. ------------ 
  11.  
  12. This program provides a English/Japanese (kana &  kanji)  display  of  selected 
  13. entries  of a dictionary file.  While it will work (more or less) with any text 
  14. file containing a mix of Japanese and  English  words,  it  has  been  designed 
  15. specifically  to operate on a dictionary in the "EDICT" format used by the MOKE 
  16. (Mark's Own Kanji Editor) Japanese text editor.  Its operating environment  has 
  17. been  designed  to  be  similar  to  MOKE's,  and  it uses the same environment 
  18. variables and control file as MOKE. 
  19.  
  20. The executable code and documentation of JDIC is hereby released to the "public 
  21. domain".  All usage of this program is at the user's  risk,  and  there  is  no 
  22. warranty on its performance. 
  23.  
  24. All the Japanese displayed is in kana and kanji, so if you cannot read at least 
  25. hiragana and katakana, this is not the program for you. 
  26.  
  27. INSTALLATION
  28. ------------
  29.  
  30. This  program  is  distributed  as  a "zoo" archive (jdic15.zoo) containing the 
  31. following files: 
  32.  
  33.     jdic.exe    (the executable)
  34.     jdic15.doc  (this documentation file)
  35.     jdxgen.exe  (program to generate the dictionary index file)                
  36.     jreader.exe (text reader with dictionary lookup)
  37.     jreader.doc (documentation for jreader)
  38.     edictj      (Japanese/English dictionary file) (*)     
  39.     edictj.doc  (information about the dictionary) (*)
  40.     *.bgi       (Borland Graphics drivers for various cards)
  41.     kiascii.fnt (alternative font file for ascii characters)   
  42.     jdicutil.exe (utility program for printing, sorting, etc. the dictionary)
  43.     jdicutil.doc (documentation for jdicutil)
  44.     k16jis1.fnt  (16x16 bitmap of the 3490 "JIS1" characters) (*)
  45.     k16jis2.fnt  (16x16 bitmap of the 3388 "JIS2" characters) (*)
  46.  
  47.     [ * The edict and k16jis files may not be included in this archive as  they 
  48. are  available elsewhere.  They will be included in the version distributed via 
  49. the comp.binaries.ibm.pc newsgroup.] 
  50.  
  51. The files will need to be unpacked and copied into a  directory  on  your  hard 
  52. disk.  Rename "edictj" to "edict";  it has been called "edictj" in case you are 
  53. storing the files in the same directory as your MOKE files  (e.g.  \kanji),  in 
  54. which  case  you  need  to be careful not to overwrite MOKE's "edict" file.  In 
  55. addition,  the 16-bit JIS font files "k16jis1.fnt" and "k16jis2.fnt" must be in 
  56. this  directory.  These  latter  files may not be included in this distribution 
  57. (please check).  If you use MOKE, you have them already.  You may need to track 
  58. them down at one of the FTP sites.  In the MOKE1.1 distribution they are in the 
  59. MK11K16.ZIP archive file.  Another source is  kd100.arc,  the  KD  distribution 
  60. file. 
  61.  
  62. The executable (jdic.exe) will need to be stored in a directory on your path if 
  63. you  wish  to  invoke JDIC from any directory.  The simplest approach is to add 
  64. \kanji to your path. 
  65.  
  66. The  following  environment  variables  may be set (note that they are the same 
  67. environment variables used by MOKE.) 
  68.  
  69.     bgi=directory  (the  directory  containing  the  bgi files.  E.g.  c:\tc or 
  70.     c:\kanji.  If this is not present,  the bgi files must be in the  directory 
  71.     in which JDIC is invoked.  Alternatively you can specify a bgi directory in 
  72.     the "moke.rc" file (see below).) 
  73.  
  74.     mokerc=directory  (the  directory  containing  the   moke.rc   file.   E.g. 
  75.     c:\kanji.  If  this  is  not  present,  the current directory alone will be 
  76.     searched for a file called moke.rc, and the details extracted.) 
  77.  
  78.     jgraphic=ATT (set this to ATT400 if you have an AT&T high-resolution  card. 
  79.     Otherwise  it  will  default to CGA.  NB:  MOKE does not use this variable. 
  80.     Again, you can also specify ATT in the "moke.rc" file.) 
  81.                                                                               
  82. MOKE.RC
  83. -------
  84.  
  85. The "moke.rc" file contains control information relating to  the  operation  of 
  86. MOKE.  JDIC  examines  this  file,  if  it  is  present,  and  adjusts  its own 
  87. environment (colours,  directories,  etc.) accordingly.  (If you use MOKE,  you 
  88. will  have  a  moke.rc  file  already.)  A  "moke.rc" file is not necessary for 
  89. successful operation of JDIC,  however it is the  only  way  for  the  user  to 
  90. specify screen colours. 
  91.  
  92. The  environment  variable  "mokerc"  may  be  used  to  specify  the directory 
  93. containing "moke.rc".  Otherwise the file must be in the directory  from  which 
  94. JDIC is invoked. 
  95.  
  96. The  file contains one or more lines of text,  each comprising a key-word and a 
  97. value. The key-words recognized by JDIC are: 
  98.  
  99.     kanjipath    directory-path    (e.g. C:\KANJI)
  100.  
  101. If you wish to operate JDIC from other directories,  you must have this line to 
  102. tell the program the location of the control and font files. 
  103.  
  104.     graphicstype  ATT
  105.  
  106. Use this if you have an ATT400 graphics adaptor, otherwise the auto-detect will 
  107. set the operation to CGA. 
  108.  
  109.     bgipath       directory-path
  110.  
  111. This is an alternative to using the "BGI" environment variable. 
  112.  
  113.     asciicolor    <colour>
  114.     backcolor     <colour>
  115.     kanjicolor    <colour>
  116.     progcolor     <colour>
  117.  
  118. Use  these to set the colours to be used for English text,  Japanese text,  the 
  119. screen background and the  control  information.  The  available  colours  are: 
  120. black,  blue, green, cyan, red, magenta, brown, lightgray, darkgray, lightblue, 
  121. lightgreen, lightcyan, lightred, lightmagenta, yellow and white. 
  122.  
  123.  
  124. OPERATION
  125. ---------
  126.  
  127. JDIC must operate on a PC or AT with a  graphics  card.  It  has  been  written 
  128. using  Turbo  C  2.0,  and  has  been tested on VGA,  CGA,  ATT and HERC cards. 
  129. Auto-detection is used to determine the type of graphics card,  except  in  the 
  130. case of an ATT board (see above). 
  131.  
  132. The invocation of JDIC is: 
  133.  
  134.     jdic  <options> <dictionary-file>
  135.  
  136. If  no  dictionary  is  specified,  it  is  assumed  to be "edict" in the local 
  137. directory, or in the directory specified by the "kanjipath" in moke.rc. 
  138.  
  139. JDIC also needs an index file "<dicname>.jdx".  If is not present it will  need 
  140. to  be created by running the utility program JDXGEN (see below).  JDXGEN saves 
  141. the length of the dictionary file and the JDIC version in the .jdx file, and if 
  142. JDIC detects a mismatch, it will refuse to operate. 
  143.  
  144. The commandline options are: 
  145.  
  146.     -bnn
  147.     
  148.     this restricts the number of 1K buffers used to hold the dictionary to  nn. 
  149.     The default is for JDIC to get as many buffers as it can, up to the size of 
  150.     the dictionary. 
  151.     
  152.     -l 
  153.     
  154.     this inhibits JDIC from loading the dictionary initially.  The program will 
  155.     start more quickly, but will operate more slowly (at first) as the pages of 
  156.     the dictionary are loaded on demand. 
  157.  
  158.     -f
  159.  
  160.     forces the use of the 8x8 bgi fonts for English text. The default is to use 
  161.     the bit-mapped fonts from the kiascii.fnt  file,  however  the  display  of 
  162.     these can be slow on an 8088 PC. 
  163.  
  164. Operation of JDIC is very simple.  After loading the dictionary, index and font 
  165. files,  the full-screen working window is  displayed  with  the  "Search  Key:" 
  166. prompt.  Type a few letters from the *start* of the word you are seeking.  JDIC 
  167. does not match on keys in the middle of words.  The scan is case-insensitive. 
  168.  
  169. A  multi-line  display  is produced of all the dictionary entries which contain 
  170. matches with the search key.  The display format is: 
  171.  
  172.      matched_word [kanji] (yomikata) english_1, english_2, etc 
  173.  
  174. where "matched_word" is either ascii or kana,  depending on the search key.  If 
  175. the  search  key  was kana (i.e.  the match was on the yomikata),  the separate 
  176. yomikata display is omitted. 
  177.  
  178. A line is only displayed once per search, regardless of the number of matches. 
  179.  
  180. If the search resulted in more entries than will fit on  a  screen,  a  further 
  181. prompt  occurs  at  the  bottom of the screen giving you the option of quitting 
  182. (Q),  requesting another search (A) or requesting  the  next  screen-full  (M). 
  183. After the last screen of a search, the "Search Key:" prompt returns. 
  184.  
  185. Exit from JDIC may be requested at any time by using the "Escape" key. 
  186.  
  187. KANA SEARCHING
  188. --------------
  189.  
  190. You  will notice an "(A)" in the bottom lefthand corner of the screen.  This is 
  191. to indicate you are entering search keys in ascii code (i.e.  in  English).  If 
  192. you press F3 before entering a key,  you toggle between (A)scii, (H)iragana and 
  193. (K)atakana. (Why F3?, well that is the key that MOKE uses for this function.) 
  194.  
  195. To  enter  a search key in kana,  type it in romaji and it will be converted to 
  196. kana as you type.  The romaji->kana translation is  almost  identical  to  that 
  197. used  in MOKE,  i.e.  for a small "tsu" you can type either a double consonant, 
  198. e.g.  "shippai",  or "t-",  e.g.  shit-pai,  and for "n" you can type  "n'"  if 
  199. necessary (e.g. as in "hon'ya").  Most of the time just typing ordinary Hepburn 
  200. or  kunrei  romaji  works.  Note that the romaji must follow the kana style for 
  201. long vowels. Tokyo must be toukyou, NOT tookyoo. 
  202.  
  203. The matching of kana keys is  insensitive  to  whether  they  are  katakana  or 
  204. hiragana. 
  205.  
  206. The display is in "dictionary" order for the words matched,  i.e.  alphabetical 
  207. for the ascii search,  and EUC order for the kana search.  EUC  order  is  very 
  208. close  to  the  "gojuun"  kana  order  in  Japanese dictionaries except that it 
  209. separates the syllables with nigori and maru. 
  210.  
  211. [JDIC also supports MOKE's "SKK" mode for entering  search  keys.  Ctrl-J  will 
  212. cause a switch from ascii mode to hiragana,  "l" will switch from kana to ascii 
  213. and "q" will toggle between hiragana and katakana.] 
  214.  
  215. DISPLAY MODES
  216. -------------
  217.  
  218. An "Unlimited Display Mode" is invoked by pressing  F1  before  or  during  the 
  219. entering  of the search key.  In this mode you will just keep scrolling through 
  220. the dictionary instead for stopping when you run out of  matching  words.  Also 
  221. in  this  mode  entries  are displayed every time there is a match in the index 
  222. table (normally an entry is displayed once only.) This mode is useful for doing 
  223. maintenance on the dictionary, and for just browsing.  If you use this mode you 
  224. may get some strange displays for entries which begin with  kana  and  continue 
  225. with kanji, e.g. ocha. 
  226.  
  227. A "Maintenance Mode" can be toggled on and off using F2 before  or  during  the 
  228. entering  of  the  search  key.  When  in  this mode the byte offset within the 
  229. dictionary of the matched word is displayed at the end of each line.  Also  the 
  230. number  of page faults (if any) when reading the dictionary is displayed at the 
  231. top left-hand corner of the screen.  The word "MAINT" is displayed at  the  top 
  232. of  the  screen when this mode is on,  along with the number of dictionary page 
  233. buffers.  This mode is useful for maintenance of edict,  which is now too large 
  234. to edit in a single file, and for monitoring the dictionary paging mechanism. 
  235.  
  236. DICTIONARY 
  237. ---------- 
  238.  
  239. Clearly  to  be  of  any  use,  JDIC  must  have  a reasonably good dictionary. 
  240. Optionally included with this distribution is the EDICTJ dictionary,  which  is 
  241. the  author's  extension of MOKE's EDICT.  MOKE's EDICT was about 1900 entries, 
  242. and was compiled by Mark Edwards with help from Spencer Green.  EDICTJ  is  now 
  243. nearly  6000 entries.  (You can rename it `EDICT' and use it with MOKE;  it has 
  244. been called EDICTJ to reduce the chance of accidental clobbering.)  EDICTJ  and 
  245. edictj.doc are available separately from several archives. 
  246.  
  247. The  dictionary  file must use the "EUC" coding for Japanese characters.  Files 
  248. using JIS codings can be converted to EUC using MOKE  itself,  or  Ken  Lunde's 
  249. "JIS.C" program. 
  250.  
  251. The format each entry of EDICT is: 
  252.  
  253. Kanji [kana] /english_1/english_2/..../ 
  254.         or
  255. kana /english_1/english_2/..../ 
  256.  
  257. JDXGEN
  258. ------
  259.  
  260. JDXGEN is a utility program that parses the dictionary file and produces a file 
  261. <dictionary-name>.jdx containing the index table (see below).  Its operation is 
  262. similar to JDIC in that it uses moke.rc to establish the path to the dictionary 
  263. and  will  operate  either  on  a  dictionary called "edict" (the default) or a 
  264. user-specified name. There are no other options. 
  265.  
  266. JDXGEN does an in-RAM sort of its index table.  As this involves a large buffer 
  267. and far pointers it is quite slow.  The 6000 entry dictionary results in  about 
  268. 23000 entries in the index, which takes about 8 minutes to sort on an XT. 
  269.  
  270. TECHNICAL
  271. ---------
  272.  
  273. JDIC holds as much as it can of the complete dictionary in RAM,  along with the 
  274. first 3490 bitmaps of the JIS character set and  the  index  table.  The  index 
  275. table  contains an entry for each word in the dictionary,  sorted in alpha/kana 
  276. order.  This enables a fast search to be done,  and for the display  to  be  in 
  277. alphabetical order by keyword.  Common words like: "of", "to", "the", etc.  and 
  278. grammatical terms like: "adj", "vi", "vt", etc. are not indexed. 
  279.  
  280. If the complete dictionary will not fit in RAM,  the missing portions  will  be 
  281. paged in as they are required,  using the good old LRU replacement method.  The 
  282. index table is also paged in as required. 
  283.  
  284. If  a  kanji is required that is not in the ~3000 most common ones,  it is read 
  285. from disk into a cache buffer. This happens rarely. 
  286.  
  287. JDIC/JDXGEN  can  cope  with  dictionaries up to about 350 kbytes.  JDIC itself 
  288. could handle a larger dictionary; the limitation is JDXGEN's in-RAM sort.  If a 
  289. larger dictionary ever comes available, another version of JDXGEN could operate 
  290. using a disk sort. 
  291.                  
  292. JDIC VERSIONS
  293. -------------
  294.  
  295. Changes in Version 1.1
  296.  
  297. o ATT graphics card handling via an environment variable.
  298. o fixes to the parsing of kanji/kana keys.  The result is that the .jdx file 
  299.   is about 20% larger than in V1.0. 
  300.  
  301. Changes in Version 1.2
  302.  
  303. o fixes to the kana->romaji code to handle "nyu" properly.
  304. o facility to use dictionaries other than "edict".
  305. o Unlimited Display Mode.
  306.  
  307. Changes in Version 1.3
  308.  
  309. o immediate romaji->kana conversion
  310. o  examination  of  the  "bgi"  and  "mokerc"  environment  variables,  and the 
  311.   "moke.rc" control file. 
  312.  
  313. Changes in Version 1.4
  314.  
  315. o  reformatting  the  output  to start with the `hit' word,  to put parentheses 
  316.   around the kanji and kana, and to position the ascii text better with respect 
  317.   to the kana/kanji. 
  318. o handling of an index table greater than 64k bytes.
  319.  
  320. Changes in Version 1.5
  321.  
  322. o inclusion of Maintenance Mode
  323. o fixing of the backspace, so that it works in kana entry mode.
  324. o demand paging of the dictionary file and index table
  325. o removal of the .jdx generation into a separate program 
  326. o command-line options
  327. o emulation of MOKE's SKK option
  328. o use of colours as specified in moke.rc (*)
  329. o extraction of ATT graphics request and bgi directory from moke.rc (*)
  330. o use of the alternative ascii font (*)
  331. o inclusion of correct romaji conversion for mya, myu and myo (*)
  332. o modified handling of "-" in hiragana.(*)
  333.    (*) these items track changes to be made in MOKE V2.1
  334.  
  335. IT DOESN'T WORK!
  336. ----------------
  337.  
  338. Oh  dear.  If  you  do  not  get the introductory message,  you probably have a 
  339. corrupted .exe.  Try and get a clean copy.  Also your  environment  might  have 
  340. trouble with the output of a Turbo C 2.0 compilation/link. 
  341.  
  342. If you actually get started,  but cannot find any thing,  even when you put "a" 
  343. as a search key,  delete your .jdx file and start again.  If it  still  doesn't 
  344. work, mail the author a sample of your dictionary and copies of you 
  345. autoexec.bat and config.sys files. 
  346.  
  347. ACKNOWLEDGEMENTS
  348. ----------------
  349.  
  350. A message from the author: 
  351.  
  352. I wrote this program to gain experience in handling and displaying the Japanese 
  353. character set, and to exploit the dictionary that came with my copy of MOKE.  I 
  354. also  wanted to brush up my C skills.  I make no great claims for it,  but I am 
  355. pleased how it turned out. Suggestions, comments and constructive criticism are 
  356. most welcome. 
  357.  
  358. While I wrote most of  this  program,  lumps  of  it  were  lifted  with  minor 
  359. modifications  from  "KD" (Kanji Driver),  which was written by Izumi Ohzawa at 
  360. Berkeley,  in particular the JIS handling module (kjis.c) which was a  port  of 
  361. "jis.pas" by Seiichi Nomura and Seke Wei. 
  362.  
  363. Ken Lunde's "japan.inf" and his elegant "jis.c" explained the workings  of  EUC 
  364. and old/new JIS codes. 
  365.  
  366. Mark Edwards' MOKE remains the tour de force in this field,  and an inspiration 
  367. for us all.  I regard JDIC as a humble and minor  accessory  to  MOKE.  (I  use 
  368. tables  lifted  from  two of the ".hlp" files in MOKE to drive the romaji->kana 
  369. code.) 
  370.     
  371. My thanks to Mark Edwards, David Cowhig, Theresa Martin and Stephun Chung for 
  372. their helpful comments and suggestions.
  373.  
  374. Jim Breen
  375. Department of Robotics & Digital Technology
  376. Monash University
  377. Melbourne, Australia
  378. (jwb@monu6.cc.monash.edu.au)
  379.  
  380. May-December 1991                  
  381.  
  382.